test(security): prove @PreAuthorize and the actuator boundary are enforced - #187

The Inspector's origin (http://localhost:6274) is the default value of
mcp.cors.allowed-origins — a plain property with nothing asserting it. Narrowing
it, or setting MCP_CORS_ALLOWED_ORIGINS=*, silently stops the Inspector
connecting and no test notices.

The wildcard is the trap worth guarding. setAllowedOrigins is the strict API, so
* alongside allowCredentials(true) does not open the server up — it rejects every
origin including the Inspector's, with nothing logged. An operator reaching for *
to "allow everything" gets the opposite.

Replays the preflight a browser sends on the Inspector's behalf: origin echoed
back specifically (not a wildcard, which is invalid with credentials),
credentials allowed, and GET/POST/DELETE all permitted since Streamable HTTP uses
each for a different part of the transport. Plus the negative case, so the
allowlist is not decorative.

Verified by mutation: flipping the default to * fails two of the three.

379 tests, 0 failures.

Signed-off-by: Aditya Parikh <aditya.m.parikh@gmail.com>

The three tests on this branch were marked @DisabledInNativeImage on the
rationale that they are "Testcontainers-backed and proxy-dependent". Neither
half of that is a reason in this repo, and the annotation cost real coverage.

Every other @DisabledInNativeImage on main is a Mockito unit test. The dividing
line is when the proxy is synthesised: ByteBuddy builds subclasses at runtime,
which GraalVM's closed world forbids, whereas Spring's @configuration and AOP
proxies are emitted by AOT at build time. processTestAot duly generates
CollectionService$$SpringCGLIB$$0/1.class alongside CGLIB classes for
MethodSecurityConfiguration, HttpSecurityConfiguration and Spring Security's
AuthorizationProxyWebConfiguration, so @PreAuthorize is fully AOT-visible.
Testcontainers-backed integration tests are what nativeTest exists to exercise;
the three existing @activeprofiles("http") tests already run there.

Measured with ./gradlew nativeTest -Pnative on GraalVM CE 25.0.2:

    234 successful / 0 failed / 142 skipped

against 227 / 0 / 142 at the branch point (a84033b). That is +7 passing with the
skip count unchanged, which is the figure that matters: had the tests traded the
annotation for a silent skip, skipped would have risen to 149 instead.

This is not tidying. Before this branch no executing test ever built a
security-enabled Spring context — the other http-profile tests set
http.security.enabled=false, and OtlpExportIntegrationTest is @disabled over an
unrelated container issue. Keeping the annotation would have left that true for
the native image, so nothing would verify that the native-http artifact enforces
authorization at all.

Signed-off-by: Aditya Parikh <aditya.m.parikh@gmail.com>

MethodSecurityEnforcementTest asserted only that an anonymous call to a
@PreAuthorize-gated tool is rejected. That is half a contract: a rejection test
cannot distinguish "correctly denies anonymous callers" from "denies every
caller". Both are green, so a gate wedged permanently shut looks identical to a
working one.

That gap was not hypothetical. A secured tool call was for a time believed
broken — reported as returning "Access Denied" even for a valid token — and no
test existed that could contradict it. The report turned out to be false (the
token variable was empty), but establishing that required standing up Keycloak
and a live server, because the suite had nothing to say either way.

Adds authenticatedCallToSecuredToolSucceeds: @WithMockUser installs an
authenticated principal, list-collections is invoked through the Spring proxy,
and must return. Mutation-checked to confirm it has teeth — with
list-collections changed to @PreAuthorize("hasRole('NONEXISTENT')"), which
denies authenticated callers while leaving the anonymous path unchanged:

  unauthenticatedCallToSecuredToolIsRejected   PASSED
  authenticatedCallToSecuredToolSucceeds       FAILED

Only the new test catches it, which is exactly the scenario that went
undetected.

Adds spring-security-test to the test bundle for @WithMockUser, declared
versionless so Spring Boot's BOM manages it (resolves to 6.5.10). It is
testImplementation only, so it does not reach productionRuntimeClasspath and
does not affect the generated binary LICENSE appendix. The annotation also
clears the SecurityContext after the method, so the ThreadLocal cannot leak
into the rejection test and make it order-dependent.

Full suite: 380 tests, 0 failures, 0 errors, 7 skipped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011VuxVJU4FuPBPkb8ye7oTF
Signed-off-by: Aditya Parikh <aditya.m.parikh@gmail.com>

Two cleanups to the security tests.

Replace magic literals with the constants Spring already provides:

- raw 200/401/403        -> HttpStatus.OK/UNAUTHORIZED/FORBIDDEN.value()
- "GET"/"POST"/"DELETE"/"OPTIONS" -> HttpMethod.<M>.name()
- "Origin", "Access-Control-Request-Method", "Access-Control-Request-Headers",
  "Access-Control-Allow-Origin", "Access-Control-Allow-Credentials",
  "Access-Control-Allow-Methods" -> the matching HttpHeaders constants
- "content-type,authorization" -> HttpHeaders.CONTENT_TYPE / AUTHORIZATION
- "true" -> Boolean.TRUE.toString()

preflight() now takes an HttpMethod rather than a String, so a typo is a
compile error instead of a silently failing preflight. Repeated endpoint paths
are named constants (HEALTH_PROBE, SBOM_ENDPOINT, METRICS_ENDPOINT,
MCP_ENDPOINT), and the transport method list becomes TRANSPORT_METHODS.

Assert the denial status definitively. assertDenied accepted "401 or 403",
which would pass for a chain that silently lost its bearer-token entry point or
gained one it should not have. Measured against the running context: both
denied actuator paths return 403, never 401 — this class configures no issuer,
so HttpSecurityConfiguration skips the OAuth2 wiring, no
BearerTokenAuthenticationEntryPoint is installed, and Spring Security falls
back to Http403ForbiddenEntryPoint. The assertion now pins FORBIDDEN exactly,
and the javadoc records why 401 belongs to a different configuration that this
class does not exercise.

Full suite: 380 tests, 0 failures, 0 errors, 7 skipped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011VuxVJU4FuPBPkb8ye7oTF
Signed-off-by: Aditya Parikh <aditya.m.parikh@gmail.com>